src/tests/page.svelte.spec.ts (1)

10-41: Add a DE-locale smoke assertion to cover the new bilingual behavior.

This test now passes locale data but only validates English headings. Add a second render/assertion path for locale: "de" to catch missing or regressed German copy in critical sections.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/tests/page.svelte.spec.ts` around lines 10 - 41, Add a second
render/assertion that passes locale: "de" (mirroring the existing render call
that sets locale: "en") and assert the German headings exist using the same
helpers (page.getByRole and expect.element); specifically, re-render with
locale: "de" and add expectations for the German strings for the two critical
headings (e.g., "Technische Expertise" and "Kontakt") to catch regressions in
bilingual copy.

scripts/generate-cv-pdf.mjs (1)

16-58: Consider reusing a single Chromium instance for all targets.

Current behavior is correct, but launching one browser per locale adds avoidable overhead in CI.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/generate-cv-pdf.mjs` around lines 16 - 58, The code launches a new
Chromium instance inside generatePdfForTarget for every target, which is
inefficient; refactor to launch the browser once (e.g., in generateAllPdfs),
pass the shared browser instance into generatePdfForTarget (add a parameter like
browser or open pages inside generateAllPdfs), create a new page per target,
call page.goto, page.pdf, and close each page after use, and finally close the
browser once after Promise.all completes to avoid per-target browser launches
and reduce CI overhead.

package.json (1)

13-13: Optional: move the long local PDF command into a script file.

This would make troubleshooting and future edits much easier than keeping all logic inline in package.json.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@package.json` at line 13, The long inline npm script "generate:cv-pdf:local"
should be moved into a standalone shell script (e.g., generate-cv-pdf-local.sh)
to simplify editing and debugging; create a script that runs the same steps (bun
run build, start preview via "bun run preview:ci" in background, trap to kill
PID on exit, poll the two endpoints /en/cv/ and /de/cv/ up to 30s, fail with the
same message if not ready, then run "bun run generate:cv-pdf") and make the
package.json "generate:cv-pdf:local" entry a short call to that script (e.g.,
"bash scripts/generate-cv-pdf-local.sh"), ensuring executable bit and identical
behavior to the original inline command.

src/routes/[lang=lang]/+layout.ts (1)

3-6: Add JSDoc for the layout load function.

This new function is missing inline API documentation.

Suggested fix

+/**
+ * Exposes the current locale from the matched `[lang=lang]` route segment.
+ */
 export const load: LayoutLoad = ({ params }) => {
     return {
         lang: params.lang as "en" | "de"
     };
 };

As per coding guidelines, **/*.{js,ts,svelte}: “Always write sensible JSDoc comments for functions and components.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/`[lang=lang]/+layout.ts around lines 3 - 6, Add a JSDoc block
above the exported load function (export const load: LayoutLoad) that describes
the purpose of the loader (returns the current language for the layout),
documents the function parameter (params with params.lang possible values "en" |
"de"), and documents the returned object shape (object with lang: "en" | "de");
reference the load function and the LayoutLoad type in the comment and keep the
wording concise and actionable.

src/tests/content.integrity.spec.ts (1)

12-12: Extend integrity assertions to both locales.

Line 12 hardcodes en, so this suite won’t catch missing/empty German content files.

Suggested fix

-function readContentFile(fileName: string): string {
-    const filePath = path.resolve("src/lib/content/en", fileName);
+function readContentFile(locale: "en" | "de", fileName: string): string {
+    const filePath = path.resolve("src/lib/content", locale, fileName);
     return fs.readFileSync(filePath, "utf-8");
 }
@@
-        for (const fileName of requiredFiles) {
-            const content = readContentFile(fileName).trim();
-            expect(content.length, `${fileName} should not be empty`).toBeGreaterThan(0);
+        for (const locale of ["en", "de"] as const) {
+            for (const fileName of requiredFiles) {
+                const content = readContentFile(locale, fileName).trim();
+                expect(content.length, `${locale}/${fileName} should not be empty`).toBeGreaterThan(0);
+            }
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/tests/content.integrity.spec.ts` at line 12, The test currently hardcodes
the English locale when resolving content files (see filePath and
path.resolve("src/lib/content/en", fileName)), so it misses German files; update
the test to iterate over both locales (e.g., ['en','de']) and run the same
integrity assertions for each locale by building filePath with
path.resolve("src/lib/content", locale, fileName) (or equivalent) and reusing
fileName/assertion logic so both locales are checked. Ensure any test
descriptions reflect the locale being checked so failures indicate which locale
failed.

src/routes/[lang=lang]/+page.server.ts (1)

12-15: Add JSDoc for the localized load function.

Please document what this loader returns for the language-prefixed route.

📝 Proposed update

+/**
+ * Loads portfolio content for the locale from the language route parameter.
+ */
 export const load: PageServerLoad = ({ params }) => {
     const locale = params.lang as Locale;
     return loadPortfolioContent(locale);
 };

As per coding guidelines: `**/*.{js,ts,svelte}`: Always write sensible JSDoc comments for functions and components.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/`[lang=lang]/+page.server.ts around lines 12 - 15, Add a JSDoc
comment above the exported PageServerLoad function `load` describing its
purpose, parameters and return value: explain that it accepts the route params
object and extracts `params.lang` (typed as Locale), that it returns the result
of `loadPortfolioContent(locale)` (describe the shape or type of that returned
portfolio content), and mention any thrown errors or edge cases (e.g., invalid
locale). Place the JSDoc immediately above the `export const load:
PageServerLoad = ({ params }) => { ... }` declaration and use plain/concise
descriptions for param and return tags.

src/routes/+page.server.ts (1)

5-6: Add JSDoc to load for consistency with TS file conventions.

The implementation is good; it just needs a brief function doc block.

📝 Proposed update

+/**
+ * Loads portfolio content for the default locale.
+ */
 export const load: PageServerLoad = () => {
     return loadPortfolioContent(DEFAULT_LOCALE);
 };

As per coding guidelines: `**/*.{js,ts,svelte}`: Always write sensible JSDoc comments for functions and components.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/`+page.server.ts around lines 5 - 6, Add a concise JSDoc block
above the exported load function describing its purpose (loads portfolio content
for the default locale), the fact that it uses DEFAULT_LOCALE and calls
loadPortfolioContent, and what it returns (the PageServerLoad data/Promise).
Place the comment immediately above the symbol `load` (export const load:
PageServerLoad) and mention `DEFAULT_LOCALE` and `loadPortfolioContent` in the
description so the intent and return shape are clear and consistent with TS file
conventions.

src/routes/[lang=lang]/cv/+page.server.ts (1)

12-15: Add JSDoc for the CV locale load function.

Please add a short description for what data is loaded from the language route param.

📝 Proposed update

+/**
+ * Loads CV content for the locale from the language route parameter.
+ */
 export const load: PageServerLoad = ({ params }) => {
     const locale = params.lang as Locale;
     return loadCvContent(locale);
 };

As per coding guidelines: `**/*.{js,ts,svelte}`: Always write sensible JSDoc comments for functions and components.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/`[lang=lang]/cv/+page.server.ts around lines 12 - 15, Add a JSDoc
block immediately above the export const load function that documents that load
is a PageServerLoad handler which reads the route parameter params.lang (cast to
Locale) and returns the CV content by calling loadCvContent(locale); include a
short description, the param description for params (or locale) and the return
type/what is returned (CV content), referencing the function names load and
loadCvContent and the Locale type so reviewers can find the implementation
quickly.

src/routes/cv/+page.server.ts (1)

5-6: Add JSDoc for load to match repository standards.

The function is concise and correct, but it still needs a short JSDoc block.

📝 Proposed update

+/**
+ * Loads CV content for the default locale.
+ */
 export const load: PageServerLoad = () => {
     return loadCvContent(DEFAULT_LOCALE);
 };

As per coding guidelines: `**/*.{js,ts,svelte}`: Always write sensible JSDoc comments for functions and components.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/cv/`+page.server.ts around lines 5 - 6, Add a short JSDoc block
above the exported load function to match repository standards: document that
export const load: PageServerLoad returns the CV content by calling
loadCvContent with DEFAULT_LOCALE, include a one-line description and an
`@returns` tag describing the returned PageServerLoad data shape (or Promise) and
optionally reference loadCvContent/DEFAULT_LOCALE for context; place the JSDoc
immediately above the load declaration so it applies to the load symbol.

src/routes/cv/+page.svelte (2)

1-14: Add a brief component-level doc comment for the locale/render contract.

A short comment near Line 1 describing locale derivation and locale-specific Markdown component selection will make this component easier to maintain.

As per coding guidelines **/*.{js,ts,svelte}: “Always write sensible JSDoc comments for functions and components.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/cv/`+page.svelte around lines 1 - 14, Add a short JSDoc-style
component comment at the top of the file explaining that this Svelte page reads
props via $props(), derives the current locale into the locale store using
$derived (defaulting to "en"), uses t(locale) to build a UI translation store
(ui), and conditionally selects the Markdown components Experience and Education
based on locale === "de"; reference the relevant symbols: $props, locale,
$derived, t, ui, Experience, Education, ExperienceDe, ExperienceEn, EducationDe,
EducationEn so future maintainers understand the locale/render contract and
markdown component selection.

---

25-37: Move download button labels into ui.cv translation keys.

Line 29 and Line 36 are still hardcoded copy. Localizing via ui keeps all UI text in one place and avoids drift.

♻️ Proposed change

-                CV (EN)
+                {ui.cv.downloadEn}
@@
-                Lebenslauf (DE)
+                {ui.cv.downloadDe}

// i18n-copy.ts (outside this range)
cv: {
  // ...
  downloadEn: "CV (EN)",
  downloadDe: "Lebenslauf (DE)"
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/cv/`+page.svelte around lines 25 - 37, The two download anchor
labels ("CV (EN)" and "Lebenslauf (DE)") are hardcoded; replace them with the
corresponding i18n keys ui.cv.downloadEn and ui.cv.downloadDe from the shared
copy (i18n-copy.ts) using the project's existing translation helper (the same
callsite used elsewhere in this page/component), leaving the anchor attributes
(href, target, rel, classes) intact and ensuring those keys are added under the
cv block in i18n-copy.ts.

src/lib/server/content-loader.ts (2)

195-198: Add inline intent comments for the regex parsing rules.

Line 195 and Line 198 use non-trivial regex transformations; one-line inline comments will reduce maintenance risk.

As per coding guidelines **/*.{js,ts,svelte}: “Use inline comments to explain complex logic, such as Regex patterns or intricate state management.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/server/content-loader.ts` around lines 195 - 198, Add brief inline
intent comments explaining the two regex operations around the block that
extracts front-matter-like key/value pairs: annotate the RegExp(/^-
\*\*(.+?):\*\*\s*(.+)$/) used in the match = ... line to state it captures lines
like "- **Key:** Value" and what each capture group represents, and annotate the
.replaceAll(/\[(.*?)]\((.*?)\)/g, "$2") on fields[key] to explain it strips
markdown links to keep only the URL (capture group 2). Place the comments
immediately above or to the right of the expressions near the variables match
and fields[key] so future readers understand intent without changing logic.

---

108-109: Decouple link parsing from hardcoded anchor text labels.

Line 108 and Line 137 through Line 138 currently depend on specific link text. Parsing by markdown link shape is more locale-safe and less brittle.

♻️ Suggested direction

- const link = lines.find(l => l.includes("[View Certificate]"))?.match(/\(([^)]+)\)/)?.[1];
+ const link = lines
+   .map(line => line.match(/\[[^\]]+]\(([^)]+)\)/)?.[1])
+   .find((url): url is string => Boolean(url));

Also applies to: 137-138

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/server/content-loader.ts` around lines 108 - 109, The current parsing
for certificate links relies on hardcoded anchor text like "[View Certificate]"
(the variable link assigned via lines.find(...)) which is brittle; change the
logic in content-loader.ts to detect markdown links by shape instead of label by
matching the markdown link pattern /\[.*?\]\(([^)]+)\)/ across the relevant
lines (the code that assigns link on the first occurrence and the similar logic
at lines ~137-138). Update both places to extract the URL from any markdown link
match (optionally filtering by file-extension or context if multiple links
exist) rather than checking for specific link text so parsing works regardless
of locale/label changes.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

src/lib/server/content-loader.ts (2)

118-119: Avoid English-only link label matching in parsers.

Lines 118, 138, 147, and 148 rely on exact English link labels. In localized markdown, certificate/project URLs can be missed even when links exist.

♻️ Proposed refactor

-        const link = lines.find(l => l.includes("[View Certificate]"))?.match(/\(([^)]+)\)/)?.[1];
+        const link = lines.join("\n").match(/\[[^\]]+\]\(([^)]+)\)/)?.[1];

-        const linksStart = lines.findIndex(l => l.startsWith("[GitHub]") || l.startsWith("[Live Demo]"));
+        const linksStart = lines.findIndex(l => /\[[^\]]+\]\(([^)]+)\)/.test(l));
         const rawContentLines = lines.slice(contentStart, linksStart > -1 ? linksStart : undefined);
         const rawContent = rawContentLines.join("\n").trim();
@@
-        const github = lines.find(l => l.startsWith("[GitHub]"))?.match(/\(([^)]+)\)/)?.[1];
-        const liveDemo = lines.find(l => l.startsWith("[Live Demo]"))?.match(/\(([^)]+)\)/)?.[1];
+        const links = lines.flatMap(line =>
+            [...line.matchAll(/\[[^\]]+\]\(([^)]+)\)/g)].map(match => match[1])
+        );
+        const github = links.find(url => /github\.com/i.test(url));
+        const liveDemo = links.find(url => !/github\.com/i.test(url));

Also applies to: 138-148

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/server/content-loader.ts` around lines 118 - 119, The current parser
uses an English-only label match (e.g., lines.find(... includes("[View
Certificate]") ) which misses localized link labels; replace these exact-label
checks (the code that computes the variable link in content-loader.ts and the
similar occurrences later) with a language-agnostic link extraction: parse all
markdown links (e.g., capture all \[text\]\(url\) occurrences) or use a
markdown-link extractor, then filter the extracted URLs by their path/hostname
patterns (case-insensitive) that identify certificates/projects (for example
match /certificate|cert|project|portfolio/ or your app’s known URL segments) to
pick the correct URL; apply this same change to the other spots that rely on
exact English link text.

---

205-219: Make contact key parsing locale-agnostic.

Line 207 stores raw markdown keys, but Lines 212-218 only read English canonical names. This is brittle for translated labels (e.g., Rolle, Telefon, Standort).

♻️ Proposed refactor

-    const fields: Record<string, string> = {};
+    const fields: Partial<Record<keyof Contact, string>> = {};
+    const contactKeyAliases: Record<string, keyof Contact> = {
+        name: "name",
+        role: "role",
+        rolle: "role",
+        location: "location",
+        standort: "location",
+        phone: "phone",
+        telefon: "phone",
+        email: "email",
+        "e-mail": "email",
+        linkedin: "linkedin",
+        github: "github"
+    };

     for (const line of lines) {
         const match = new RegExp(/^- \*\*(.+?):\*\*\s*(.+)$/).exec(line);
         if (!match) continue;
-        const key = match[1].toLowerCase();
-        fields[key] = match[2].replaceAll(/\[(.*?)]\((.*?)\)/g, "$2").trim();
+        const rawKey = match[1].toLowerCase().trim();
+        const key = contactKeyAliases[rawKey];
+        if (!key) continue;
+        fields[key] = match[2].replaceAll(/\[(.*?)]\((.*?)\)/g, "$2").trim();
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/server/content-loader.ts` around lines 205 - 219, The parsing
currently stores raw lowercased markdown keys into fields (via match and key)
but the return reads only English keys (fields.name, fields.role, etc.), so make
the parser locale-agnostic by normalizing label text to canonical keys before
assigning: add a small mapping (e.g., labelMap) from known localized variants
(e.g., "rolle","position","telefon","telefonnummer","standort", etc.) to
canonical names ("role","role","phone","phone","location"), sanitize match[1]
(trim, remove trailing colons/whitespace) and look up the canonical key
(fallback to the cleaned key itself) and then assign fields[canonicalKey] = ...;
finally leave the return as-is so fields.name/role/... resolve regardless of
input language.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

src/routes/+layout.svelte (2)

25-25: Redundant conditional for identical values.

localizedSiteTitle returns the same string for both locales. Either simplify to a constant or implement actual localization if different titles are planned.

Simplify if titles remain identical

-    const localizedSiteTitle = $derived(locale === "de" ? "Colin Mörbe | Portfolio" : "Colin Mörbe | Portfolio");
+    const localizedSiteTitle = "Colin Mörbe | Portfolio";

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/`+layout.svelte at line 25, The conditional assigning
localizedSiteTitle is redundant because both branches return the same string;
replace the conditional expression in localizedSiteTitle with a simple constant
assignment of "Colin Mörbe | Portfolio" or, if you intend real localization,
wire localizedSiteTitle to a proper localization lookup (e.g., use your
i18n/gettext function or a translations map) so the title is resolved via locale
instead of the current ternary in localizedSiteTitle.

---

321-325: "Skip to content" link is not localized.

This accessibility text should be translated for German users.

Suggested localization

 <a
     href="#main-content"
     class="sr-only z-60 rounded bg-blue-600 px-3 py-2 text-white focus:not-sr-only focus:fixed focus:top-3 focus:left-3 focus-visible:ring-2 focus-visible:ring-blue-400">
-    Skip to content
+    {ui.layout.skipToContent}
 </a>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/`+layout.svelte around lines 321 - 325, Replace the hardcoded
"Skip to content" anchor text with a call to the app's i18n/localization helper
(use the existing localization pattern in the project) and use a key like
"skip_to_content"; update the anchor in +layout.svelte (the <a ...> element with
class "sr-only z-60 ...") to render the localized string instead of the literal
text and add the corresponding German translation entry (e.g.,
"skip_to_content": "Zum Inhalt springen") to the German locale file so German
users see the translated label.

src/routes/+page.svelte (1)

293-322: Form field labels are not localized.

The contact form labels ("Name", "Email", "Message") remain hardcoded in English while other UI strings use ui.home.* translations. Consider adding these to the i18n copy for consistency.

Suggested localization

 <div class="flex flex-col gap-1">
-    <label for="name" class="text-sm font-medium">Name</label>
+    <label for="name" class="text-sm font-medium">{ui.home.formName}</label>
     ...
 </div>
 <div class="flex flex-col gap-1">
-    <label for="email" class="text-sm font-medium">Email</label>
+    <label for="email" class="text-sm font-medium">{ui.home.formEmail}</label>
     ...
 </div>
 <div class="flex flex-col gap-1">
-    <label for="message" class="text-sm font-medium">Message</label>
+    <label for="message" class="text-sm font-medium">{ui.home.formMessage}</label>
     ...
 </div>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/`+page.svelte around lines 293 - 322, Replace the hardcoded labels
"Name", "Email", "Message" with translation keys and use the existing i18n
lookup in the Svelte template; add keys ui.home.name, ui.home.email, and
ui.home.message to your locales (all language JSON/YAML files) and then update
the labels in +page.svelte to render the translations for the inputs with
id/name "name", "email", and "message" (e.g., use your project's translation
helper like $t('ui.home.name') or $_('ui.home.name') depending on your i18n
setup).

Configuration used: defaults

Review profile: CHILL

Plan: Pro

src/lib/components/CertificateCard.svelte (1)

1-10: Add a brief component/props JSDoc block

This component currently has no JSDoc/TSDoc despite updated public props. Add a short doc block describing purpose and prop semantics (title, info, link, ctaLabel).

As per coding guidelines, "**/*.{js,ts,svelte}: Always write sensible JSDoc comments for functions and components."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/components/CertificateCard.svelte` around lines 1 - 10, Add a short
JSDoc/TSDoc block at the top of the CertificateCard.svelte component describing
the component's purpose and each prop in the Props interface (title, info, link,
ctaLabel) so it follows the project guideline to always include JSDoc for
components; update the block near the existing interface/props declaration
(reference: Props interface and the destructured const { title, info, link,
ctaLabel = "View Certificate" }) and include one-line descriptions for title
(certificate title), info (supporting text), link (optional URL to the
certificate), and ctaLabel (optional call-to-action label).

src/routes/+page.svelte (1)

74-76: Avoid duplicate/static page title overriding localized layout metadata

The hardcoded <title> here can conflict with the localized title/meta already managed in +layout.svelte. Prefer a single source of truth in layout for SEO/i18n consistency.

Proposed fix

-<svelte:head>
-    <title>Colin Mörbe | Portfolio</title>
-</svelte:head>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/`+page.svelte around lines 74 - 76, The page currently hardcodes a
<svelte:head> block with a static <title> which conflicts with the localized
metadata provided by +layout.svelte; remove the <svelte:head> / <title> from
src/routes/+page.svelte (or make it conditional) so the layout remains the
single source of truth for page title/metadata, and if you need page-specific
titles instead expose/consume a prop or exported value from +layout.svelte to
set the localized title rather than overriding it directly in +page.svelte.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

src/routes/+layout.svelte (1)

25-30: Centralize meta description text in the i18n copy object.

This locale ternary duplicates translation ownership inside layout while the rest of UI copy is already centralized via t(locale). Moving this text into the same copy source reduces drift and translation misses.

Proposed refactor

-    const localizedSiteDescription = $derived(
-        locale === "de"
-            ? "Backend Software Engineer Portfolio mit Projekten, Berufserfahrung, Tech-Stack, Zertifikaten und downloadbarem Lebenslauf."
-            : "Backend Software Engineer portfolio with projects, professional experience, technical skills, certificates, and a downloadable CV."
-    );
+    const localizedSiteDescription = $derived(ui.layout.siteDescription);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/`+layout.svelte around lines 25 - 30, The meta description string
is hard-coded with a locale ternary in localizedSiteDescription; move both
German and English description texts into the existing i18n copy object used by
t(locale) (e.g., add keys like site.description.de and site.description.en),
then replace the ternary with a lookup through t(locale) (use the same t and
locale variables already in scope) so localizedSiteDescription obtains its value
from the centralized copy instead of inline conditional strings.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

src/lib/server/content-loader.ts (1)

107-122: Consider defensive handling for empty sections.

If a malformed Markdown file has an empty section after ## , lines[0] at line 111 could be undefined, and calling .trim() would throw. While the content is controlled, a defensive check would improve robustness.

Suggested defensive fix

 function parseCertificates(content: string): CertificateEntry[] {
     const sections = content.split(/^## /m).slice(1);
     return sections.map(section => {
         const lines = section.split("\n");
-        const title = lines[0].trim();
+        const title = lines[0]?.trim() ?? "";
         const infoLine = lines.find(l => l.startsWith("_") && l.endsWith("_"));

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/server/content-loader.ts` around lines 107 - 122, In
parseCertificates, empty sections produced by splitting on /^## /m can yield
lines[0] === undefined, so guard against that by skipping empty sections or
setting safe defaults: check section.trim() and continue/filter out empty
sections before mapping, or within the map ensure const title = (lines[0] ??
"").trim(); likewise protect infoLine and link extraction by only processing
when lines.length > 0; update parseCertificates to return valid CertificateEntry
objects (or omit entries) when section content is missing to avoid calling
.trim() on undefined.

src/routes/+layout.svelte (1)

13-16: Consider using the shared locale validation.

The locale derivation hardcodes the check for "de" and defaults to "en". While functional, consider using the isLocale helper from $lib/i18n for consistency with the route parameter matcher, which would make the code more maintainable if additional locales are added later.

Suggested refactor

+    import { getAltLocale, isLocale, type Locale } from "$lib/i18n";
-    import { getAltLocale, type Locale } from "$lib/i18n";
     ...
     const locale = $derived.by<Locale>(() => {
         const first = page.url.pathname.split("/").filter(Boolean)[0];
-        return first === "de" ? "de" : "en";
+        return isLocale(first) ? first : "en";
     });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/routes/`+layout.svelte around lines 13 - 16, The locale derivation
currently hardcodes "de" vs "en" in the const locale = $derived.by<Locale>(...)
block; replace that manual check by importing and using the isLocale helper
(from $lib/i18n) to validate the first path segment (extracted from
page.url.pathname) and return the validated Locale (or fallback to "en"). Update
the derived function to call isLocale(first) and return first when true else
"en", keeping the Locale type and $derived.by<Locale>() wrapper intact.

Configuration used: defaults

Review profile: CHILL

Plan: Pro